A. Field of the Invention
This invention generally relates to distributed systems and, more particularly, to a method and apparatus for determining a state of remote objects in a distributed system.
B. Description of the Related Art
Distributed systems typically comprise multiple machines, such as computers and related peripheral devices, connected in a network, for example, a Local Area Network (LAN), Wide Area Network (WAN), or the Internet. Distributed systems generally require that computational entities (e.g., applications, programs, applets, etc.) running in different address spaces, potentially on different machines, be able to communicate.
For a basic communication mechanism, distributed object-oriented systems utilize Remote Method Invocation (RMI), which is more generally known as Remote Procedure Call (RPC). RMI facilitates application-level communication between xe2x80x9cobjectsxe2x80x9d residing in different address spaces.
In object-oriented systems, a xe2x80x9cclassxe2x80x9d provides a xe2x80x9ctemplatexe2x80x9d for the creation of xe2x80x9cobjectsxe2x80x9d (which represent items or instances manipulated by the system) having characteristics of that class. The term xe2x80x9ctemplatexe2x80x9d denotes that the objects (i.e., data items) in each class, share certain characteristics or attributes determined by the class. Objects are typically created dynamically during system operation. Methods associated with a class are generally invoked (i.e., caused to operate) on the objects of the same class.
RMI is the action of invoking a method of a remote object. In response to the invocation of a method on a remote object using RMI, a lower level communications process causes the invoked method to be executed on the remote object.
The Java(trademark) runtime system, which is designed to implement applications written in the Java(trademark) object-oriented programming language, supports a specific Java(trademark) RMI Application Program Interface (API). This API is explained in, for example, a document entitled xe2x80x9cRemote Method Invocation Specification,xe2x80x9d Sun Microsystems, Inc. (1997), which is available via universal resource locator (URL) http://java.sun.com/products/jdk/1.1/docs/guide/rmi/spec/rmiTOC.doc.html, and is incorporated herein by reference. The Java language is described in many texts, including one that is entitled xe2x80x9cThe Java Language Specificationxe2x80x9d by James Gosling, Bill Joy, and Guy Steele, Addison-Wesley, 1996. Java and all Java-based trademarks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
Java RMI assumes a homogeneous environment of the Java runtime system, and therefore Java RMI takes advantage of the object model for the Java language whenever possible. In the Java(trademark) distributed object model, a remote object is one whose methods can be invoked from another Java runtime system, potentially on a different machine. A remote object is defined by one or more remote interfaces written in the Java language that specify the methods of the remote object. For example, interfaces enable entities invoking methods on remote objects to define the methods supported by the remote objects without specifying the implementation of those methods.
xe2x80x9cGarbage collectionxe2x80x9d is the term used in technical literature and the relevant arts to refer to a class of algorithms utilized to carry out storage management, specifically automatic memory reclamation. There are many known garbage collection algorithms, including reference counting, mark-sweep, and generational garbage collection algorithms. These, and other garbage collection techniques, are described in detail in a book entitled xe2x80x9cGarbage Collection, Algorithms For Automatic Dynamic Memory Managementxe2x80x9d by Richard Jones and Raphael tins, John Wiley and Sons, 1996.
Distributed garbage collection extends the notion of garbage collection to the realm of distributed computing systems, reclaiming resources when no application on any computer in a distributed system refers to them. An automated distributed garbage collection process frees the programmer from determining when it is safe to delete a remote object. In the absence of a distributed garbage collector (DGC), a remote object would need to keep track of all clients that refer to the object and the object storage can be reclaimed when all clients no longer reference that object. For this function, Java RMI""s DGC relies on a reference-counting garbage collection algorithm similar to Modula-3""s Network Objects. See xe2x80x9cNetwork Objectsxe2x80x9d by Birrell, Nelson, and Owicki, Digital Equipment Corporation Systems Research Center Technical Report 115, 1994.
To accomplish reference-counting garbage collection, the Java RMI runtime system, which is an implementation of Java RMI on top of the Java runtime system, keeps track of all remote objects referenced by computational entities (i.e., clients) executing through a local virtual machine (VM). The Java(trademark) VM (JVM) is an abstract computing machine of the runtime system that receives instructions from programs in the form of bytecodes and that interprets these bytecodes by dynamically converting them into a form for execution, such as object code, and executing them. The JVM is described in detail in a text entitled xe2x80x9cThe Java Virtual Machine Specificationxe2x80x9d, by Tim Lindholm and Frank Yellin, Addison Wesley, 1996.
When a computational entity references a remote object, the local RMI runtime for the computational entity increments a corresponding reference count. Such a reference is typically referred to as a xe2x80x9cstrongxe2x80x9d reference, and the computational entity is said to xe2x80x9choldxe2x80x9d a strong reference to the remote object. A strong reference is one that will prevent the (remote) object from being collected. The first reference to a remote object causes the runtime system to send a xe2x80x9creferencedxe2x80x9d message to the RMI runtime for that object (e.g., another machine in the distributed system holding the referenced object). As remote objects are found to be unreferenced in the local VM, the local RMI runtime decrements the corresponding reference count.
When the local VM discards the last reference to a remote object, an xe2x80x9cunreferencedxe2x80x9d message is sent to the RMI runtime corresponding to that object. When a remote object is not referenced by any client, the RMI runtime system for the remote object refers to its xe2x80x9clocalxe2x80x9d object (which was considered a remote object for the client) using a weak reference. The weak reference allows the remote object""s garbage collector to discard the object, provided no other local xe2x80x9cstrongxe2x80x9d references to the object exist. As in the normal object life-cycle, a finalization process is called after the garbage collector determines that no more strong references to the object exist. One type of finalization process causes the memory allocated for an object to be returned to a memory heap for reuse. As long as a local xe2x80x9cstrongxe2x80x9d reference to a remote object exists, it cannot be reclaimed in this way by a garbage collector and it can be passed in remote calls or returned to clients. Passing a remote object adds the identifier for the VM to which it was passed to the referenced set. As a result of the xe2x80x9creferencedxe2x80x9d call from the receiving VM, the RMI runtime will keep a xe2x80x9cstrongxe2x80x9d reference to the remote object to prevent collection.
A remote object needing xe2x80x9cunreferencedxe2x80x9d notification, i.e., a notification that no more clients hold references, must implement a special interface referred to as the xe2x80x9cjava.rmi.server.Unreferencedxe2x80x9d interface. In this manner, when all references to the object from remote entities (e.g., former clients of the object) no longer exist, a method named xe2x80x9cunreferencedxe2x80x9d of the object will be invoked. The unreferenced method is called when the set of references for the object becomes empty.
Note that if a network partition exists between a client and a remote object, it is possible that premature collection of the remote object will occur since the transport might believe that the client crashed. Because of the possibility of premature collection, remote references cannot guarantee referential integrity; in other words, it is always possible that a remote reference may in fact not refer to an existing object. An attempt to use such a reference will generate a RemoteException error which must be handled by the computational entity making use of the reference.
Accordingly, there is a need for a system that enables computational entities to determine the state of remote objects. By obtaining such state information, computational entities can better manage references to remote objects and avoid unwanted RemoteExceptions without preventing the remote objects from being garbage collected.
Systems consistent with the present invention, as embodied and broadly described herein, a method is provided for selectively supplying a state change associated with remote objects in a distributed system. The method involves registering a request from a computational entity to receive notification as to a state change associated with a remote object. Registration of a notification request causes the creation of a remote weak reference to the remote object including an identifier of a location of the remote object.
Periodically, a request is sent to a location based on the identifier of the remote weak reference. When it is determined that a state change associated with the remote object has occurred, the registered computational entity is notified accordingly.